On-line or Internet banking has become increasingly popular and has greatly simplified how users, customers or account holders conduct transactions and manage finances. On-line banking (OLB) allows bank customers to manage and track financial applications such as deposits, withdraws, loan amounts, credit card amounts, and other financial matters at the user's convenience, at various locations and at various times.
In known on-line systems, OLB services are provided by a host of an intermediate computer that serves as an interface between the user computer and a computer of a financial institution (FI) at which the user has an account. A browser executes on a user computer to access the intermediate computer, and an OLB program executes on the intermediate computer to access the FI computer and provide the user with on-line accesses to the account.
Referring to FIG. 1, during an OLB session, the user may request to view a copy of a check 100 that posted to the account, e.g., by clicking on a link or other check 100 identifier during an OLB session. Upon receiving the request, a check imaging program of or associated with the OLB program formulates and sends a query to an image server to retrieve the image. The image server may store images of checks 100 for that particular FI or multiple FIs. The retrieved image is then displayed to the user.
The configuration of the query submitted from the intermediate computer to the image server to retrieve the requested image is typically specified by the FI and/or host of the image server or formulated in view of FI and/or image server host requirements. For example, referring to FIG. 1, it may be required that the query include certain information such as data in the Magnetic Ink Character Recognition (MICR) line 110 of a check 100. The MICR line is used by FIs to allow computers to read check 100 data and may include the Routing and Transit Number (RTN) 112, account number 114 or other identifier, which may have a particular format based on the account number, check number 116 and other information identifying the check 100. The query configuration may also involve data such as user or account holder identification information such as name 122 and address 124, check amount 132 and date 134.
As a further example, the query may be required to include certain information about the image server from which the image is to be retrieved. The FI may use a particular image vendor for scanning checks 100 and storing the images at an image server such that the query must be configured to identity the particular location (e.g., URL address) of the image server and a protocol for communicating with the image server. The image server provides a particular application program interface (API) that is utilized to retrieve the image files from the image server.
Thus, there may be a number of constraints on how queries for images of checks 100 are configured. Thee constraints may be even more restrictive and complicated when there are changes involving the user, FI and/or image server host such that query configurations that are utilized do not have the correct configuration data and thus fail to retrieve the requested image.
For example, the user's FI may have been acquired by another FI or merged with the other FI, which has its own check 100 format and different MICR line 110 data. Further, the user may have and use checks 100 with two different formats, e.g., two different MICR lines 110 with different routing numbers 112 and account numbers 114 due to the change involving the FI. The user may utilize some or all of the remaining original checks 100 for a certain time or until they run out and then transition to the new checks 100 with the updated information. The other FI may also use a different or multiple image vendors who scan and store physical checks 100 and different image servers that are at different locations or Uniform Resource Locator (URL) addresses and have their own communication protocols and APIs. Further, certain information on old checks may be outdated, e.g., if the user moved and changed addresses or had a name change due to marriage or divorce.
The host of the intermediate computer may not be notified of these changes such that the query configuration provided by the FI to the host and utilized to submit a request for a check image results in failure to retrieve the image even if the image is stored at the image server. In these cases, the user is not able to view the check image. Other times, the host may be informed of the changes by the FI, and if multiple query configurations are utilized (e.g., pre- and post-merger or based on old and new check or MICR data), the FI specifies a sequence of query configurations to be utilized for image retrieval. The FI may specify that the post-merger checks or query format be utilized as the primary query configuration, and queries structured according to the specified sequence are submitted until the image is retrieved or there are no other query configurations to utilized and the user is informed that the image cannot be retrieved.
Current systems and methods for retrieving check images, therefore, involve multiple and unnecessary requests and communications between computers, which involves additional bandwidth and query response and image retrieval delays, and potential failure to retrieve the image when the image is available due to use of the wrong query configuration. These shortcomings result in user inconvenience and frustration and negatively impact the user's OLB experience. Further, users may call the host of the OLB program regarding the inability to view check images, thus requiring additional time and costs to address image retrieval failures.